In recent years, a technology called OpenFlow has been proposed (see NPL 1 and NPL 2).
OpenFlow sees communications as end-to-end flows and performs routing control, fault recovery, load balancing, and optimization on a per-flow basis. An OpenFlow switch, whose specifications are defined in NPL 2, includes a secure channel for communicating with an OpenFlow controller and operates according to a flow table to which instruction for addition or rewriting are given by the OpenFlow controller as may be necessary.
A flow table contains, for each flow, a set of definitions of matching conditions against which a packet header is compared (Header Fields); flow statistics information (Counters); and actions defining specific processing (Actions) (see Section 3 “Flow Table” in NPL 2).
Upon receipt of a packet, an OpenFlow switch searches the flow table for a flow entry that has matching conditions matching the header information in the received packet (see Section 3.1 “Header Fields” and Section 5.2.3 “Flow Match Structures” in NPL 2). When the OpenFlow switch finds any flow entry matching the received packet after searching the table, the OpenFlow switch updates the flow statistics information and performs on the received packet the actions written in the Actions field in the flow entry (for example, forwarding a packet from a specified port, flooding, or dropping). When the OpenFlow switch finds no flow entry matching the received packet after searching the table, the OpenFlow switch transmits a request for setting a flow entry (in other words, a request for sending control information for processing the received packet) to the OpenFlow controller via the secure channel. Such request message is called a Packet-In message. Then, after receiving from the OpenFlow controller a flow entry that defines specific processing, the OpenFlow switch updates the flow table. In this way, an OpenFlow switch forwards a packet using a flow entry stored in the flow table as control information.
Centrally-controlled networks, such as OpenFlow among others, allow for highly granular control on a per-flow basis. On the other hand, however, limitation of resources such as the restricted number of flow tables that a switch device can handle is imposed on such networks. To handle large-scale flows, this resource limitation may be problematic. Techniques to optimize utilization of resources by switch devices are described in, for example, NPL 3 and NPL 4. NPL 3 and NPL 4 respectively propose a technique and the like for efficient use of resources for the switch devices needed for forwarding over a core network by rewriting, at network edge switches, a header so as to embed path information for individual flows, while, in the core network, setting common flow entries that can be shared by existing flows.
Each application on a system employing OpenFlow is developed and implemented so that such optimization technique is incorporated according to the applicable environment. In this case, the application will be modified in order to use any new emerging optimization technology.
NPL 5 describes separating an application from a flow setting device (OpenFlow controller) to make them independently exchangeable, by introducing a theoretical network model and a network flow representation expressing data forwarding rules in the network model and by programming an application so as to operate such model. The technique described in NPL 5 can suppress an increase in man-hours for development.